Stream broadcasting is generally contrasted with broadcasting by the downloading of files in which all the data of a content needs to be retrieved before it can be listened to or watched. However, from the theoretical viewpoint, streaming is a form of downloading because there is an exchange of raw data between a customer and a server, but the storage is temporary and does not appear directly in the form of files on the recipient's hard disk drive.
Stream broadcasting is used especially for video on demand (VOD) services and live program transmission or live streaming.
It is generally possible to distinguish between three types of streaming:                traditional streaming which enables “continuous playing”. Only one file, containing the same information several times, is broadcast with different levels of quality, and a specialized server is responsible for the broadcasting of information adapted (to the connection bitrate of the customer and to the bandwidth). The exchanges between server and customer can use a standardized protocol (for example the RTP or Real Time Transport Protocol or the RTSP or Real Time Streaming Protocol) or a proprietary protocol (for example MMS or Microsoft Media Services which is owned by Microsoft) or RTMP (Real Time Messaging Protocol which is owned by Adobe Systems);        pseudo-streaming (also called “progressive downloading”) which enables “progressive playing”. This pseudo-streaming relies on the HTTP (HyperText Transfer Protocol) and does not require any specialized server (a standard HTTP server being sufficient). The audio or video file is simply proposed when downloading and it is the customer who sees to it that the file is played, starting before the file is completely downloaded;        adaptive streaming which generally relies on the HTTP protocol (although it can be used with other customer-server communication protocols). It is based on the gradual downloading by the customer of small segments of the content (multimedia stream). The duration of these segments, also called chunks, is for example from 2 to 4 seconds. Adaptive streaming is therefore an adaptation of the second streaming technique presented here above (progressive downloading). It is adaptive in that each segment is chosen by the customer from several segments having the same content but encoded with different bitrates. The main formats currently available for adaptive streaming are “HTTP Live Streaming” (HLS), proposed by Apple, “Smooth Streaming” (SS), proposed by Microsoft, “HTTP Dynamic Streaming” (HDS), proposed by Adobe, and “Dynamic Adaptive Streaming over HTTP” (DASH or MPEG-DASH), proposed by MPEG.        
In the present description, the term “adaptive streaming” is understood to mean also the particular case (although it is not adaptive in the above-mentioned sense) in which there is only one bitrate available for each segment.
Here below in the description (and in the context of the present invention), the focus will be on techniques of broadcasting by adaptive streaming that rely on the use of a playlist also known as a manifest, an index or an MPD (media presentation description).
A playlist is a file that contains an ordered sequence of references to media files. Typically, the reference of a media file is a uniform resource identifier (URI) such as for example a uniform resource locator (URL). Media files are of short duration (for example from 1 to 10 seconds) and can be read in sequence to build a continuous, partial or complete media presentation. In the case of adaptive streaming, these short-duration media files correspond to the segments or chunks mentioned further above. The playlist and the segments are not located locally on the player but on a remote server to which the player must send a request in order to get a playlist and the segments. The player downloads and analyzes the playlist. Then, it downloads, analyses, decodes and renders the referenced segments in the playlist in order to render the media presentation (on video for example).
For example, in the solution proposed by Apple and described especially in the document “HTTP Live Streaming Overview”? the architecture of the system of broadcasting by adaptive streaming comprises:                a preparation component comprising a media encoder which delivers an encoded media content (for example in the MPEG-2 TS format) and a stream segmenter which divides the encoded media content into segments (small media files of short duration) and also creates a playlist or index file containing the references of the segments (and more specifically the URL addresses of the segments). The segmenter can create several playlists for a same content, each list referencing encoded segments with a different bitrate. In one alternative embodiment, the segmenter can create one single playlist for a given content, this single list referencing encoded segments with different bitrates. For example, in the case described further above of a playlist comprising a URI template, this playlist comprises a bitrate identifier (for example: http://server/cnn/{bitrate}/{timestamp}). The segments and the playlists are saved in the “.ts” format and the “.M3U8” format respectively;        a distribution component comprising a server which delivers the playlist or lists and the segments of each playlist to the customer (player device or player) via the HTTP protocol;        a customer component comprising the player which retrieves the playlist or playlists from the server. Using the content of the retrieved playlist or lists, the player sequentially downloads the segments (with the bitrate desired for each segment) and renders them to the user in the form of a continuous stream. Thus, in the multi-bitrate case, all the segments of the sequence downloaded by the player are not at the same bitrate.        
In practice, the content delivery network or CDN is implemented between the servers and the players. Since this CDN network is transparent relative to the mechanisms described here above and here below in the description, it shall not be described. Solely with a view to simplifying the description, the player shall be considered here below to be directly transmitting its requests to the server.
Two types of playlists can be distinguished:                those that directly contain the references of the segments. In receiving a playlist, the customer device receives the URI (for example in URL form) of each segment. This is for example the case in the “HTTP live streaming” (HLS) solution by Apple, with the player file that contains the URL addresses of the segment;        those that do not directly contain the references of the segments but contain two complementary pieces of information: a URI template (for example a URL template) and a list of segment identifiers (for example a list of timestamp information, a list of indices, etc). It is the player that rebuilds the reference (for example the URL) of each segment by combining the template and the identifier (the timestamp) of this segment. This is for example the case in the “smooth streaming” (SS) solution by Microsoft, with a playlist called a “customer manifest” which contains pieces of information such as types of stream, parameters, bitrates and segment timestamp information (or timestamps).        
In the case of the broadcasting of a content in VOD mode, the playlist contains information (direct or indirect references) on all the segments of the content.
In the case of a live program broadcast or live streaming, this is not possible: in the HLS solution by Apple, the playlist is downloaded repeatedly by the customer (player device) which thus permanently has an updated list of the last available segments; in the SS solution by Microsoft, each segment contains information (lookahead information) enabling the customer to access the next segment (or a few following segments). Hence, no downloading of an updated playlist is needed.
There are several applications that require an adaptation (i.e. a customizing) of the content of the playlist to each user (player) especially:                Ad insertion: the final content played by the player comprises segments of advertisements which are introduced between certain segments of the initial content and/or instead of certain segments of the initial content. An ad decision server (ADS) can be used to decide which advertisement is to be inserted for each customer (for example depending on the geographical area in which he is located). The ad segments can be provided by an advertisement server or ad server; and        Program substitution: in certain situations, rights over the contents do not permit the broadcasting of a program in a region, and the player must therefore be given a substitute program. For example, a sports event in a stadium can be broadcast nationwide but must be blocked at the local level (for example in the city in which it takes place) and replaced by another content so as not to cause a drop in attendance at the stadium.        
To adapt of the content of the playlist in this way, an splicer, also called a playlist manipulator or “splicer”, acts between the server (giving the initial playlist and the segments) and the player.
Should the playlist directly contain the references of the segments (this is the case of the HLS solution by Apple with a playlist comprising a list of URLs of segments), the splicer modifies the playlist by introducing ad segment URLs. This is done according to information provided by the player (in the get-list requests) and pertaining for example to the user (geographical location, sex, age, etc).
In the HLS solution, for a VOD content, the splicer inserts for example references (URLs) of ad segments at the start of the playlist returned to the player (or else at another position of the playlist, indicated by a piece of “placement opportunity information”. These references point towards segments of one or more advertisements, targeted for example according to the geographical area of the user of the player.
In the HLS solution, for live content or live streaming, the segmenter inserts for example specific markers which are associated with certain segment references in the playlist and enable the identifying of the start and the end of the insertion of ad segments in the original content. The splicer can then replace the preliminarily marked segments references by ad segment references. These segments point towards segments of one or more advertisements, targeted for example according to the geographical area of the user of the player.
Should the playlist not directly contain the references of the segments (this is the case of the SS solution by Microsoft, with a playlist comprising a URL template and a list of segment identifiers), the splicer cannot directly introduce modifications, into the playlist, aimed at introducing references to ad segments located on a server different from the one storing the segments of the content requested by the user (VOD content or live program). Indeed, the playlist enables the player to generate only references (URLs) pointing towards the location that is hard-coded in the URL template. For this reason, in known implementations, as insertion in a playlist based on a template (i.e. comprising a template and a list of segment identifiers) is done by adding additional information to the playlist indicating that an advertisement break occurs at a certain point in time. Thus, the player can apply an ad insertion logic, in contacting an ad server that returns ad segments to be read during the advertisement break, instead of the segments of the original content.
One drawback of this last-named technique is that it is the player that ultimately personalizes the content. To manage this mechanism, the player must be adapted as a personalized player. This makes it more costly to use since it requires a particular development and entails maintenance overheads.